OMU トラブルシューターの初仕事

概要

あなたの友人の A さんは、図1に示すネットワークを構築しました。このネットワークは以下のような設定がなされています。

  • 各ルータ間はスタティックルーティングを行っている
  • pc から srv01srv02 にアクセスできる
  • srv01srv02 間はアクセスできない

図1
図1

次に、rt01rt03 を直接接続することで、 pc から srv02 へのアクセスのレイテンシを改善できるのではないかと考えました。ネットワーク構成を図2のように変更しようとしています。

  • 各ルータが OSPF で接続されている


図2

しかし、設定を間違えてしまい、pc から各サーバへアクセスできなくなってしまいました。

あなたは A さんに代わって、ダイナミックルーティングを使用したネットワークに変更してください。

また、A さんは以下のメモを残しています。

  • ダイナミックルーティングに移行するにあたって、いくつかスタティックルーティングの設定を削除した。
  • srv01 と srv02 の通信を拒否するために、rt03 に ufw というコマンドでファイアウォールを設定した覚えがある。

前提条件

  • スタティックルートの経路は追加しないこと
  • 全てのホストに割り当てられた IP アドレスを変更してはいけない
  • 接続可能なホストには、192.168.1.0/24 の接続用アドレスが割り当てられている
  • srv01 にファイアウォールを設定してはいけない

初期状態

  • pc から srv01 および srv02 へアクセスできない

終了状態

  • pc から srv01 および srv02 へアクセスできる
  • pc から srv02 への経路は、pc -> rt01 -> rt03 -> srv02 となる
  • srv01 から srv02 へはアクセスできない
  • ダイナミックルーティングを用いた経路交換がなされている

補足

ルータの設定

rt01, rt02, rt03 では、FRRouting を用いて OSPF が動いています。次のコマンドで FRR の設定を行うことができます。

sudo vtysh

コマンド例

# 現在の設定を表示する
show running-config

# vtysh を終了する
exit

解説

この問題は、OSPFの設定を行ったにも関わらず、期待どおりに経路交換が行われない、というものです。

この問題では3つの設定ミスが複合して発生しています。

  1. rt01 に不必要なスタティックルートの設定がある
  2. rt01, rt02 の OSPF の設定において、router-id が重複している
  3. rt03 に誤ったファイアウォールの設定がある

このため、これら3つ全てを解決することで、終了状態を満たすことができます。

想定していた解法

1.

rt01rt02 の間で router-id が重複しないように設定する必要があります。
ここでは rt02 の router-id を 2.2.2.2 に変更します。

sudo vtysh

rt02# configure
rt02(config)# router ospf
rt02(config-router)# ospf router-id 2.2.2.2
For this router-id change to take effect, use "clear ip ospf process" command
rt01(config-router)# end

なお、この後設定を適用するためには、vtysh内での clear ip ospf process, clear ip ospf neighbor <neighbor> といったコマンドの実行や、 sudo systemctl restart frr など、何らかの形でOSPFのプロセスやネイバーを再起動/再接続する必要があります。

2.

rt01 の FRRouting のコンフィグを確認すると、次のスタティックルートの経路を確認できます。

ip route 172.16.40.0/26 172.16.0.2

恐らく、A さんの以前の設定が残っているのでしょう。
この設定により、pc から srv02 までの経路がpc -> rt01 -> rt02 -> rt03 -> srv02 となっています。

次のようにコマンドを実行することでトラブルとなっている経路を削除できます。

rt02# configure
rt02(config)# no ip route 172.16.40.0/26 172.16.0.2

3.

rt03 のufwのstatusを確認すると、次の設定を確認できます。

user@rt03:~$ sudo ufw status numbered
Status: active

     --                         ------      ----
[ 1] 22                         ALLOW IN    192.168.0.0/16
[ 2] 80                         ALLOW IN    172.16.0.0/24

恐らく、A さんの以前の設定が残っているのでしょう。
この設定により、OSPFのパケットの交換が行えなくなっています。

次のようにコマンドを実行することで、OSPFのパケットを受信することが可能となります。

  • sudo ufw del 2
  • sudo ufw route deny from 172.16.30.0/27 to 172.16.40.0/26
  • sudo ufw default allow
  • sudo ufw reload

なお、他にも /etc/ufw/before.rules でプロトコル番号89の通信を許可する、自身のアドレスとマルチキャストアドレス宛のパケットを許可するなどでもOSPFのパケット交換を可能とすることができます。

採点基準

  • pc から srv01へアクセスできる
    • +30%
  • pc からsrv02 へアクセスできる
    • +20%
  • pc からsrv02 へアクセスでき、srv01 からsrv02 へアクセスできない
    • +20%
  • pc から srv02 への経路は、pc -> rt01 -> rt03 -> srv02 となる
    • +20%
  • 完答ボーナス
    • +10%
  • スタティックルートの経路を追加
    • -100%
  • 全てのホストに割り当てられた IP アドレスを変更してはいけない
    • -100%

講評

この問題は3つの原因が複合して発生したものであり、3つ全てを解決しないと満点解答とならない問題でした。
更に、OSPFとファイアウォールの組み合わせということもあり、ある程度難しい問題と考えて出題しました。
この問題で満点解答を提出したチームは6チームあり、大凡想定通りの難易度となったかなと感じています。

このトラブルの3つの原因の中ではスタティックルートの修正が最も簡単なものかとは思いますが、この箇所について気づいていない解答が多かったように感じます。

また、 rt03 におけるufwの設定にて、マルチキャストアドレス宛パケットの受信のみを許可し、ユニキャストでのパケット受信は拒否したままの解答が存在しました。
こちらについては、終了状態を満たし正常に通信が可能であること、採点基準において減点対象とならないことから、満点としました。
しかし、通信状態として必ずしも適正であるとはいえないため、実際に設定する際はユニキャストアドレスでの受信を許可するルールも必要となります。